Question Loading...

In early JavaScript engines, GC was fully stop-the-world—the entire program paused while the collector ran, causing noticeable UI jank in browsers and latency spikes in Node.js .

As web applications grew more complex, these pauses became unacceptable. A full GC cycle could take 100-300ms, causing dropped frames and poor user experience .

The challenge: the GC needs to traverse the entire object graph and cannot safely do so while JavaScript is modifying it, creating a fundamental tension .

Instead of marking all live objects in one long pause, the GC marks incrementally in small slices interleaved with JavaScript execution .

Each slice does a fixed amount of marking work (e.g., traversing a certain number of objects), then yields back to JavaScript .

This spreads a 100ms pause across 10ms slices over 10 task iterations—completely imperceptible to the user .

The challenge: JavaScript can modify object references between slices. Write barriers track these changes to ensure correctness .

Incremental marking reduced main thread pause times by 70% in V8 compared to stop-the-world marking .

Modern hardware has multiple cores. V8 uses helper threads to perform marking entirely in the background while JavaScript continues running on the main thread .

The main thread occasionally synchronizes with helper threads but doesn't wait for them. This is true concurrency, not parallelism .

Write barriers still needed: when JavaScript modifies an object, the barrier informs the concurrent marker about the change .

Concurrent marking eliminated most of the remaining marking pauses, especially for large heaps where incremental marking still caused noticeable delays .

Young generation collections (Scavenge) are fast but still need to pause the main thread briefly because they move objects .

Modern V8 uses parallel threads during this pause—multiple helper threads work simultaneously to evacuate live objects from the nursery .

With 4 helper threads, a 4ms pause can do the work that would have taken 16ms sequentially, remaining under the 16ms frame budget .

Parallel scavenging reduced young GC pause times by 20-50% in real-world workloads .

Browsers have idle periods between animation frames and user input. V8 uses the requestIdleCallback mechanism to perform GC work during these idle times .

The GC estimates how much time is available and does as much work as possible without exceeding the budget .

Idle-time collection can perform significant GC work that would otherwise need to happen during active execution .

This is particularly effective for background tabs or applications with idle periods, like text editors between keystrokes .

Because of the generational hypothesis, most collections are young generation collections, which are inherently fast (few milliseconds) .

Young GC happens frequently but pauses briefly; old GC happens rarely but uses concurrent techniques to avoid long pauses .

The combination means that in a typical web app, 95% of GC pauses are under 5ms—well within the 16ms frame budget for 60fps .

Large, long-running apps (like Figma or Google Docs) still trigger full collections, but these are now concurrent and invisible .

Large object allocation: Allocating a huge array (e.g., 100MB) can still cause a pause because memory must be zeroed .

GC stress: Applications that allocate extremely fast may force GC to work harder, potentially causing noticeable pauses despite optimizations .

Real-time requirements: For audio processing or VR, even 5ms pauses can be problematic. These use cases may need WebAssembly or special GC avoidance techniques .

Mobile devices: Lower-powered devices have fewer CPU cores and slower memory, making concurrent GC less effective and pauses more noticeable .